Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/osigen/osigen-minutes-89july.txt

Text File | 1993-02-17 | 16KB | 489 lines

OSI Interoperability Working Group
Chairpersons:  Ross Callon/DEC and Robert Hagens/U of Wisconsin




CURRENT MEETING REPORT
Reported by Ross Callon, Rob Hagens and Richard Colella



AGENDA


     Monday, July 24th

        o Discussion and review of GOSIP V2

     Tuesday, July 25th

        o Inter-domain routing

        o Intra-domain routing

     Wednesday, July 26th

        o General Meeting

          1. BSD 4.4 Update

          2. Review of the CLNP Echo proposal

          3. Review of GOSIP comments

          4. Strategies for encapsulating CLNP in DoD IP

        o X.500

        o DEC DNS


ATTENDEES


       1. Abramowitz, Alyson/[e-mail]

       2. Alberts, Charlie/[e-mail]

       3. Barker, Trudy/[e-mail]

       4. Bierbaum, Neal/[e-mail]

       5. Blackwood, Craig/[e-mail]

       6. Brackenridge, Billy/[e-mail]

       7. Breslau, Lee/[e-mail]

       8. Brim, Scott/[e-mail]



                                        1
 9. Callon, Ross/[e-mail]

10. Chapin, Lyman/[e-mail]
11. Chi, Debra/[e-mail]


12. Colella, Richard/[e-mail]

13. Collins, Mike/[e-mail]

14. Coltun, Rob/[e-mail]

15. Deboo, Farokh/[e-mail]

16. Denny, Barbara/[e-mail]

17. Doo, Way-Chi/[e-mail]

18. Farinacci, Dino/[e-mail]

19. Fedor, Mark/[e-mail]

20. Fink, Bob/[e-mail]

21. Forster, Jim/[e-mail]

22. Galvin, James/[e-mail]

23. Garcia-Luna, J. J./[e-mail]

24. Gary Ralls, Vicki/iruucp!sun!ntrlink!ralls

25. Gerich, Elise/[e-mail]

26. Gerlach, Chuck/[e-mail]

27. Gross, Martin/[e-mail]

28. Hagens, Rob/[e-mail]

29. Hollingsworth, Greg/[e-mail]

30. Hytry, Tom/[e-mail]

31. Ilnicki, Ski/ski

32. Jacobsen, Ole/[e-mail]

33. Jarza, Peggy

34. Jones, Bill/[e-mail]

35. Jordt, Dan/[e-mail]

36. Katz, Dave/[e-mail]

37. Kincl, Norman/[e-mail]

38. Knopper, Mark/[e-mail]

39. Kullberg, Alan/[e-mail]



                                  2
40. LaQuey, Tracy/[e-mail]

41. Lebeck, Sue/[e-mail]
42. Lee, Young/[e-mail]


43. Lepp, Marianne/[e-mail]

44. Leser, Norbert/[e-mail]

45. Little, Mike/[e-mail]

46. Love, Paul/loveep@@sds.sdsc.edu

47. Lynch, Dan/[e-mail]

48. Maas, Andy/[e-mail]

49. Malkin, Gary/[e-mail]

50. Mankin, Allison/[e-mail]

51. Merritt, Don/[e-mail]

52. Mockapetris, Paul/[e-mail]

53. Mogul, Jeff/[e-mail]

54. Montgomery, Doug/[e-mail]

55. Mundy, Russ/[e-mail]

56. Nitzan, Rebecca/[e-mail]

57. Ohle, Bill/[e-mail]

58. Opalka, Zbigniew /[e-mail]

59. Oran, Dave/[e-mail]

60. Pak, Raylene/[e-mail]

61. Palmer, Howard/sun!iruucp!ntrlink!palmer

62. Pillalamarri, Shyam/shyam

63. Pugh, Jon/[e-mail]

64. Pugh, Rex/[e-mail]

65. Ramakrishnan, KK/rama

66. Reilly, Michael/[e-mail]

67. Reinstedler, Jim/[e-mail]

68. Rekhter, Yakov/[e-mail]

69. Replogle, Joel/[e-mail]

70. Reschly, Robert/[e-mail]



                                  3
      71. Roberts, Mike/[e-mail]

      72. Roselinsky, Milt/cmcvax![e-mail]
      73. Scanlan, Keely/[e-mail]


      74. Schoffstall, Martin/[e-mail]

      75. Schofield, Bruce/[e-mail]

      76. Sheridan, Jim/[e-mail]

      77. Sklowear, Keith/[e-mail]

      78. Smith, Tom/[e-mail]

      79. Sollins, Karen/[e-mail]

      80. St.  Johns, Mike/[e-mail]

      81. Stahl, Mary/[e-mail]

      82. Steenstrup, Martha/[e-mail]

      83. Stefferud, Einar/[e-mail]

      84. Sweeton, Jim/[e-mail]

      85. Tausworthe, Bob/[e-mail]

      86. Tharenos, Michael/[e-mail]

      87. Travis, Lance/[e-mail]

      88. Tsai, Howard/[e-mail]

      89. Vance, L. Stuart/[e-mail]

      90. Vaughan, Lynn/[e-mail]

      91. Volk, Ruediger/[e-mail]

      92. Wilder, Rick/[e-mail]

      93. Youssef, Mary/[e-mail]


MINUTES

The meeting was convened by co-chairmen Ross Callon and Rob Hagens.  The
major issues discussed at this meeting included:  GOSIP version 2,
inter-domain and intra-domain routing, CLNP encapsulation, and directory
services.

GOSIP V2 COMMENTS (Monday)

We went through the draft GOSIP version 2 document more or less front to
back, and agreed on the following comments (to be submitted officially as
OSIIWG comments):



                                        4
Congestion Recovery:

It was suggested that the congestion recovery mechanisms should be mandatory
in GOSIP, rather than "strongly recommended".  It was pointed out that there

is a difference between congestion recovery and congestion avoidance, and
that only the congestion recovery need be mandatory.  After a brief
discussion this proposal was accepted.

Inclusion of CO/CL indicator in SEL part of NSAP address:

Several people raised concern about the bit in the SEL part of the NSAP
address which indicates whether the network service is connectionless or
connection-oriented.  It was explained that in some cases, in the absence of
directory services, an ES which is to initiate communications may have the
remote NSAP address available, but not know whether to use the
connectionless or connection oriented network service.  By looking at the
bit in the remote NSAP address, it would know what protocol/service type to
use.  This was described as an interim measure.

This explanation raised the level of interest from mild displeasure to
serious concern.  In particular, it was clear that some people were planning
to write code which relied upon specific meaning in the SEL fields of remote
NSAP addresses.  Software written with this assumption would never be able
to interact with any end system which happened to assign the wrong value to
that bit of the NSAP address (such as non-Gosip OSI-compliant systems, or
systems implementing future or past versions of GOSIP). We quickly agreed
that this was undesirable.

NSAP format:

Other than the CO/CL bit in the SEL field, people were quite happy with the
NSAP format.  We agreed that RFC 1069 should be re-written to be compatible
with GOSIP version 2.0.

NSAP Assignment and Administration:

There was a lengthy discussion about who was to administer NSAPs.  Doug
Montgomery suggested that since they were already setting up administrative
procedures for the bulk of the Government, perhaps the same procedures
should be used for the DoD. There was also some talk about whether the same
procedures should be used for the entire Internet community, including
educational institutions and government contractors.  There was no agreement
on this last group, except that in general there was no clear distinction
between what was a government contractor and what was a private company
(which would be expected to get their assignment from ANSI). Related to this



                                        5
discussion was the issues surrounding the administration of ICD 0005 and ICD
0006.  Although ICD 0006 is delegated to the DoD (and therefore, part of the

Internet), many felt that all addresses should be registered under ICD 0005,
and ICD 0006 left empty (or for private military use).

There was also a discussion of the need for guidelines on (i) what sort of
agencies should be considered an Administrative Authority; (ii) Under what
conditions should specific grouping of networks be included in one domain,
versus being split into several domains.  We appeared to be in agreement
that in many cases the specific people who are tasked to set up domain and
address structures will be folks who do not fully understand the technical
ramifications of these choices (such as the effect on routing).  It was also
suggested that commercial companies probably have the same need for
information of value to clients setting up large networks.  It was agreed
that (i) There is a need for such guidelines; (ii) Writing these guidelines
is beyond the scope of the OSIIWG, although we would like to review and
comment upon any guidelines intended for the Internet; (iii) This was an
important issue which should be brought to the attention of the IAB and the
FRICC, but which did not result in any specific comment to GOSIP.

It was agreed that it would be preferable to describe the address
administration in a separate document from the NSAP address, rather than
postpone re-issuance of RFC 1069 in order to include both issues in one RFC.

O/R Names:

We were generally in agreement that the X.400 O/R Names section in Gosip has
problems.

Priority Processing of PDUs:

The GOSIP 2.0 spec contains a bullet item which could be interpreted to mean
that in order to conform with GOSIP you HAVE to separate incoming traffic by
priority before processing the header (which would seem to imply mostly
processing the header to find the priority, then queueing the packet, then
re-processing the header).  On the other hand, it was pointed out that in
some specific environments priority forwarding of packets is very important.
We proposed alternate wording which we feel preserves the possibility for
individual acquisition authorities to require priority handling of packets
where appropriate, while correcting the possible mis-interpretation.

Example of use of DoD Management Protocols:

In the introductory section there is a discussion of the need to use
"Tertiary" sources for protocol specifications (sources which are neither



                                        6
standards nor proposed standards).  An example was given of use of DoD
management standards (designed for use with TCP/IP) for management of OSI

systems.  We agreed that this was a poor example, and proposed a better
example (use of the ANSI MIB along with DIS version of CMIP).

General:

Various folks were tasked with writing up paragraphs describing each item,
which Ross agreed to type up for submission to NIST.

INTER-DOMAIN ROUTING (Tuesday)

We had a half day for discussion of Inter-domain Routing Protocols, which
was intended for two purposes:  (i) For information purposes, to increase
understanding of what possibilities are under development; (ii) To determine
what we want to do short term in the Internet.

Marianne Lepp (chair of the IETF Open Routing Working Group) gave a
presentation of the inter-domain architecture on which the ORWG is working,
and presented a schedule for more concrete written architectural and
protocol specifications.  Doug Montgomery gave a presentation of the NIST
scheme, which ECMA and NIST are bringing to OSI. Finally Jacob Rehkter of
IBM gave a presentation of the short-term proposal of the Interconnectivity
Working Group.

We then had a discussion of what to do for short term use in the Internet.
Yacob Rechkter asked:  "How many routing domains do we have currently in the
Internet?" (obviously the answer is none).  He then asked:  "How many will
we have in two years?" (probably not very many).  He suggested that the
number of domains will probably be very small for several years, and that we
have much more pressing problems.  So, why not just use fixed tables for
now, and in a couple of years re-visit the question (with the benefit of the
work of the other Internet groups working on this problem for TCP/IP). We
quickly agreed on this.

There ensued a brief discussion that essentially was of the question "How
fixed are fixed routing tables, and what might one offer to allow remotely
updating them".  There was no clear conclusion.



                                        7
INTRA-DOMAIN ROUTING (Tuesday)

Dave Oran gave a presentation of the DEC/ANSI intra-domain IS-IS routing
protocol, with emphasis on the changes made since the older (October 1987)

version.  Dave had a hard copy of the brand new updated proposal, which was
sent to be copied and distributed.  The new version of the ANSI IS-IS
routing spec, which will be submitted to ISO in Sept.  1989 will follow,
with luck, the following progression through ISO:


   o DP Jan, 1990

   o DIS Oct, 1990

   o IS June, 1991


GENERAL MEETING (Wednesday)

BSD 4.4 STATUS REPORT

A brief status report on 4.4 BSD was given by Rob Hagens.  The ISODE is
being ported to run over the Wisconsin lower layers.  Testing of the now
complete OSI stack will begin shortly.

ECHO OPTION FOR ISO 8473

Two mechanisms for realizing an 8473 echo request/reply were discussed by
Rob Hagens:  using a SEL value to indicate that a DT pdu should be sent to
an echo entity, or using a new type code in the pdu itself to distinguish a
DT from an echo request/reply.

The OSIIWG felt that the use of the SEL is a good short term solution.
However, the new type field is the best long term solution.  The echo draft
(not yet public) should be edited to suggest that the SEL field be used in
the short term.  Concurrent to this, the new type code should be described
in detail and submitted to ANSI as a work item.

Finally, the source route option was discussed.  Some people would like to
use it in the echo-request and have it reversed in the echo-reply.  Others
would like it not copied from echo-request to echo-reply.  Since the source
route option is currently incorrectly specified in ISO 8473, it was
suggested that the best approach is to discourage use of a source route
option when using an echo facility.

ENCAPSULATION

The OSIIWG agreed that a production encapsulation method was a necessary
transition aid.  EON, as specified in RFC 1070 is insufficient.



                                        8
The act of wrapping and unwrapping CLNP in DoD IP should be performed by
gateways.  The CLNP should run in native mode as far as possible.

There are actually 3 sub-problems:


a) The wrapper/unwrappers must know of each other of the purpose of network
layer routing.  b) The wrapper (when acting as a SNDCP for CLNP) must obtain
the mapping from NSAP address to SNPA (DoD IP address) of the unwrapper.  c)
It is not clear if the CLNP packet should be placed directly into the DoD IP
data field, or if a small header should be used.  The header might contain
the NSAP/DoD IP address mapping of the wrapper.  The general consensus was
not to include this extra header.

The routing problem (a) is similar to that experienced when X.25 is used as
an COSNS for CLNP. The group looked to the ANSI IS-IS proposal for support.
The IS-IS solution does not provide a magic solution.  A general opinion of
the group was that static tables should be used.  However, opinions varied
considerably.  The question really becomes:  how static is static?  Could we
utilize a network management protocol to adjust static tables?  This topic
requires more discussion.

The method of mapping the NSAP to DoD IP address (b) was not determined.
Again, the ANSI IS-IS spec.  was not helpful.  Possibilities include:  embed
the DoD IP address in the NSAP address, use static tables, use an SNPA
server.  This topic requires more discussion.

DIRECTORY SERVICES AND NAMING

Dave Oran gave a presentation on the DEC DNS naming scheme.  Karen Sollins
gave an ad hoc presentation on the X.500 name service.



                                        9